Business Analyst Community & Resources | Modern Analyst

Dispatches from the WCBA Conference: Jogging through the IIBA® BABOK®

Adrian M. — Tue, 17 Nov 2009 08:55:00 GMT

Here’s a dispatch from the first day at the World Congress for Business Analysts (WCBA).

I attended an all-day workshop titled “Get the Right Stuff, Fast: Jogging through the IIBA® BABOK® with the Requirements Roadmap” lead by Mary Gorman of EBG Consulting.

Mary is a Certified Business Analysis Professional™ (CBAP®) and works as Senior Associated for EBG Consulting, assisting teams to build the right products through exploring and confirming their requirements.

If Mary’s sessions was a jog, then this blog post will be a sprint – a very fast one, I might add!

The focus of the workshop was to:

Leverage the Requirements Roadmap to articulate requirements
Align requirements models to knowledge areas in the BABOK®
Create a set of interconnected requirements models to speed up the requirements development and successfully engage business users and customers.

During the session, Mary provided great insights on the business of “business analysis” specifically focusing on defining the scope of and modeling user requirements using the requirements roadmap:

You can get the PDF version of the requirements roadmap from EBG’s website.

During the session we raced (ok, just jogged) through the roadmap with pointers to sections in the various BABOK® knowledge areas:

Business Analysis Planning and Monitoring
Enterprise Analysis
Elicitation
Solution Assessment and Validation
Requirements Analysis
Requirements Management and Communication

Regardless of what methodology or techniques you use, Mary pointed out that it is important understand that we need to have a balanced perspective of the requirements through the lens of four fundamental model views:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules

The session slide included a nice Vann diagram of the four models with the control model being at the intersection of the behavior, structure, and dynamics models.

Jogging along… the session covered a number of techniques, including:

Stakeholder & Actors: Customer vs. User vs. Others => Ask: “Who?”

Glossary & Data Model: The building blocks for later constructs such as business rules => Ask: “What?”

Event-Response Tables: An effective tool to elicit user requirements => Ask: ”When?”

Use Case & Scenarios: Describe the flow of the actor-system interactions => Ask: “How?”

Business Policies & Business Rules: Statements that constrain some aspect of the business => Ask: “Why?”

The practical side of the workshop was the case study which forced everyone to roll-out their sleeves and put in practice the techniques discussed.

It was a cozy sessions with many chances for everybody to participate. Most of the session attendees got a free copy of the Software Requirements Memory Jogger.

- Adrian

Adrian Marchis
Publisher, ModernAnalyst.com

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1

ModernAnalyst.com — Sun, 25 May 2008 14:40:00 GMT

Have you ever had to use a map to get somewhere, and after navigating around the wilderness for hours, eventually had to ask for directions because it failed you?

Alternatively, have you ever read directions to assemble a toy, and rather than help you, the directions made things much more complicated?Perhaps you just figured it out on your own, without the directions.

This is what some BA’s and IT folks do all the time. They get understandable Business Requirements in hand, the bugle sounds, and IT is immediately restless in the starting gate. And they are off!Who will be the first IT hero to come up with a solution or the code which business will say yes!

In this kind of a race, there is never a finish line.The race will go on forever until all of the problems are solved; and in fact some of the problems are the results of other solutions. Finally, someone in IT draws a white line in the sand (creates a functional Design Document or something) and says to the business, 'is this ok?'If the business agrees, then the race is over. Now it's time for the next game.

Now we play a game of tag.The IT group starts coding the solution. After a while, an issue comes up and the IT folks tag a businessperson.“You're it”, say the IT folks. “When you have an answer, let us know.” (Back to Doom 10)

The businessperson comes back with an answer, and now the IT folks are tagged.This goes on until all of IT‘s questions are answered, or the business gets frustrated to a point and says, “Just do something.” As a result, someone in IT or the business erases the white line from the first game, and redraws the white line somewhere else.

Now if you’re lucky, the BA is so annoyed by this, that they says to IT, “Let's just get more precise requirements.The IT folks say no way. The business is already ticked off, and talking to them again will only tick them off more.We cannot start over, we must use what we have, and you need to sell it to them (or shove it down their throat) and make them like it. Speak their language; and it should be easy.

Therefore, the BA starts selling the solution (after finishing up his/her resume).This is where 'Do you feel lucky' comes in to play. We all know what happens from there.A two month project takes 1 ½ years and costs $1.5 million dollars and a death march.

The examples above are about being precise and understandability. Jonathan Babcock wrote a great article in his blog titled Good Requirements Are More Than Just Accurate. This is a great article; take the time to read it.

Now, since I got out all of my pent up aggression, I need a week to recover. Next week, in part 2 we will look at how we get precise and understandable requirements, and stop the games above.

By the way, I really do like IT folks. It's just that sometimes I don't like the way they do things.Ok, sometimes I hate the way they do things. In most cases, though, the IT folks are just trying to help the business, and that honorable intention is what gets us all in trouble some times...

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 2

Wed, 02 Apr 2008 04:56:00 GMT

In Part 1, we learned that the less precise things are, the easier it is to understand them. Thus the paradox: how do you get precise requirements and easy to understand requirements?

According to the requirements gods and goddesses, there are fundamentally three levels of requirements ( you can break these down into more but that is another blog):

1. Business Requirements- Why the project is being undertaken;
2. User Requirements- What users will be able to do with the product;
3. Software Requirements – What the developers need to build.

Take a look at the statements below:

Business Requirements are the easiest to understand, but the least precise;
User Requirements are more difficult to understand, however they are more precise than the Business Requirements;
Software Requirements are even more difficult to understand, yet they are the most precise.

The more perspectives you include, the more precise things get, and the less understandable things become. When we can no longer recognize where we are, we get lost and do not understand how we got there.

When we were kids, and our parents would drive us to the market to go grocery shopping, (sometimes three or more times a week since we would forget stuff) we learned how to get to the grocery store. For us, this was a good 15-20 miles away. However, after a period of time, we knew how to get there in at least two different ways: Dad’s way, and Mom’s way. Still later, we learned the way Grandpa and Grandma went to the store; now we know three ways.

One day Mom and I were on the way to the grocery store, and there was road construction. As we were waiting in the long line of backed up cars, I recognized the street Dad takes to the grocery store. I told Mom that we could get to the grocery store faster if we took Oak Street, and then State Street (I wanted my baseball cards, and my money was burning a hole in my pocket, like you would not believe). Mom looked over at me, very surprised, and said, “Good idea!” Off we went, thus now a 4th way to get to the grocery store. The key to solving our unexpected dilemma was that we had been to the store repeatedly, in different ways, opening up our options in a time of crisis.

As a good BA, we should facilitate the business and IT through each of the requirement levels by showing repeatedly how we arrived there through tractability.

Thus, developing a map on how to get from an easy understandable business requirements to user requirements, and ultimately to software requirements. People have a better chance of understanding with a map and if they do not, they should ask for a better map from the BA.

The BA acts like a tour guide (a facilitator, not a leader or manager) through the maze of requirement levels. The BA should be guiding the Business and IT team through the requirements collaboratively, and allow the groups to discover the map on their own through the process.

If you discover something through a process, you will understand it much deeper than if someone just told you.

Requirements elicitation is a gathering process, and a learning process.

If you do one without the other, you will play the “Do You Feel Lucky, Punk” Game in Part 1. So as you transition between each type of requirement, work through the transition collaboratively, in a facilitated process.

So, do you feel lucky?

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1

Thu, 20 Mar 2008 05:03:00 GMT

Have you ever had to use a map to get somewhere, and after navigating around the wilderness for hours, eventually had to ask for directions because it failed you?

Alternatively, have you ever read directions to assemble a toy, and rather than help you, the directions made things much more complicated? Perhaps you just figured it out on your own, without the directions.

This is what some BA’s and IT folks do all the time. They get understandable Business Requirements in hand, the bugle sounds, and IT is immediately restless in the starting gate. And they are off! Who will be the first IT hero to come up with a solution or the code which business will say yes!

In this kind of a race, there is never a finish line. The race will go on forever until all of the problems are solved; and in fact some of the problems are the results of other solutions. Finally, someone in IT draws a white line in the sand (creates a functional Design Document or something) and says to the business, 'is this ok?' If the business agrees, then the race is over. Now it's time for the next game.

Now we play a game of tag. The IT group starts coding the solution. After a while, an issue comes up and the IT folks tag a businessperson. “You're it”, say the IT folks. “When you have an answer, let us know.” (Back to Doom 10)

The businessperson comes back with an answer, and now the IT folks are tagged. This goes on until all of IT‘s questions are answered, or the business gets frustrated to a point and says, “Just do something.” As a result, someone in IT or the business erases the white line from the first game, and redraws the white line somewhere else.

Now if you’re lucky, the BA is so annoyed by this, that they says to IT, “Let's just get more precise requirements. The IT folks say no way. The business is already ticked off, and talking to them again will only tick them off more. We cannot start over, we must use what we have, and you need to sell it to them (or shove it down their throat) and make them like it. Speak their language; and it should be easy.

Therefore, the BA starts selling the solution (after finishing up his/her resume). This is where 'Do you feel lucky' comes in to play. We all know what happens from there. A two month project takes 1 ½ years and costs $1.5 million dollars and a death march.

Now, since I got out all of my pent up aggression, I need a week to recover. Next time we will look at how we get precise and understandable requirements, and stop the games above.

By the way, I really do like IT folks. It's just that sometimes I don't like the way they do things. Ok, sometimes I hate the way they do things. In most cases, though, the IT folks are just trying to help the business, and that honorable intention is what gets us all in trouble some times.

More on how to deal with bad requirements

Adrian M. — Sun, 24 Jun 2007 02:26:00 GMT

After posting my last entry on questioning suspect requirements, I've read a great piece on the SlickEdit blog titled "How to Design Software With Bad Requirements."

Scott offers some practical tips to help developers deal with bad requirements. These also apply very well to business analysts and systems analysts:

come up with good use cases - to help the business user visualize the system or process scenarios which do not make sense,
create a prototype - if the end user's request can be modeled using a UI prototype, do so - they may see the light,
abstract and encapsulate - assume that these requirements will change eventually and design your system in such a way to be able to easily modify it in the future,
don't get discouraged - keep your spirits up and make the best out of the situation.